- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
G´day !!
I´m using an ADC with differential output (LVDS). It´s a device including 8 ADCs with Serial LVDS output. Data from each ADC is serialized and provided on a seperate channel. This serial data (data rate for each serial stream is 700Mbps maximum) is read with Cyclon III. What´s the best way to do this ? I found the ALTLVDS Megafunction, but i think this block has no sense, cause of the serialization factor of 1 for each channel used in my system. But what´s the best way to read and process the sampled input data ?? Is it possible to wire this LVDS Serial data direct to a PIO ??? hope someone can help me greets !!!Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What ADC, I mean can you give us the Partnumber?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hey..
it´s analogs ad9252 thanks- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
TYPE RXTYPE IS ARRAY (0 to 3) of STD_LOGIC_VECTOR(13 downto 0);
SIGNAL lvds_rx : RXTYPE;
SIGNAL lvds_sr : RXTYPE;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok, i´m glad i´ve the same, but how do u write to an out port as effectively as possible ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- how do u write to an out port as effectively as possible ? --- Quote End --- Effectively in what regard? And which outport?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i just thought in giving out the result vektor (parallelized sampled data) on an output port...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
TO_BE_DONE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I didn't yet observe the reported warning and don't know why it's generated in your design. May be it's due to the ad_in2_tmp wire signal.
Actually Cyclone IV uses LE registers for ddio_in, so the warning is irrelevant in any case. You should primarly look for succesful timing closure and first of all correct operation of actual hardware design.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- I didn't yet observe the reported warning and don't know why it's generated in your design. May be it's due to the ad_in2_tmp wire signal. Actually Cyclone IV uses LE registers for ddio_in, so the warning is irrelevant in any case. You should primarly look for succesful timing closure and first of all correct operation of actual hardware design. --- Quote End --- Thx for ur reply. Shortly, I have two questions as follow:
- Could the input of ALTDDIO_IN connect the I/O input signal directly? Or the input of ALTDDIO_IN should connect particular I/O pin? When I connect I/O pin to ALTDDIO_IN directly, I got the following Warning.
Warning (176225): Can't pack node ad_ddio_in:inst_ad_ddio_in|altddio_in:ALTDDIO_IN_component|ddio_in_1di:auto_generated|input_cell_l to I/O pin
- I don't know if I should source synchronize the AD data clock(DCO) and the AD output(ad_in2). If I use a PLL to creat a clock(dco_clk) in source synchronous mode, I should do PLL compensation in Assignment Editor, or I will get this warning.
Warning (15062): PLL "ad_pll:inst_ad_pll|altpll:altpll_component|ad_pll_altpll:auto_generated|pll1" in Source Synchronous mode with compensated output clock set to clk is not fully compensated because it does not feed an I/O input register
So I added the following codes and the above warning dispears.process(dco_clk) begin if(rising_edge(dco_clk)) then ad_in2_reg <= ad_in2; end if; end process;
But in this way, I can only get the partial data of (ad_in2) because it's DDR output. So I don't know what should I do to figure this out.Could u give me some suggestions plz?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- 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). --- Quote End --- Hi josyb, I'm using an AD9252 pretty similar with AD9222. I have a question about what u said above. Did ur AD output connect with the input of DDR-in block directly? When connecting directly, I got 2 Warnings like this.
Warning (176225): Can't pack node ad_ddio_in:inst_ad_ddio_in|altddio_in:ALTDDIO_IN_component|ddio_in_1di:auto_generated|input_cell_l to I/O pin
Warning (171167): Found invalid Fitter assignments. See the Ignored Assignments panel in the Fitter Compilation Report for more information.
And the messages of Ignored Assignments are as follows.
Name: DDIO_INPUT_REGISTER
Ignored Entity:altddio_in
Ignored From:
Ignored To:input_cell_H
Ignored Value:HIGH
Ignored Source:Compiler or HDL Assignment
Name: DDIO_INPUT_REGISTER
Ignored Entity:altddio_in
Ignored From:
Ignored To:input_cell_L
Ignored Value:LOW
Ignored Source:Compiler or HDL Assignment
I don't know how to solve this problem. Could u give me some suggestions? And, should the AD outputs connect some particular I/O pins? The FPGA I'm using is EP4CE115F29. Many thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- I didn't yet observe the reported warning and don't know why it's generated in your design. May be it's due to the ad_in2_tmp wire signal. Actually Cyclone IV uses LE registers for ddio_in, so the warning is irrelevant in any case. You should primarly look for succesful timing closure and first of all correct operation of actual hardware design. --- Quote End --- Cyclone IV uses LE registers for ddio_in, but it seems that the input of ddio_in cannot connect I/O pin directly, right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- 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). --- Quote End --- I changed a way of using the ADC data clock and AD output to connect the inputs of DDR-In block directly(without PLL source synchronous mode), and there is also an invalid Fitter assignments as follows and I don't know why.
Name: DDIO_INPUT_REGISTER
Ignored Entity:altddio_in
Ignored From:
Ignored To:input_cell_H
Ignored Value:HIGH
Ignored Source:Compiler or HDL Assignment
Name: DDIO_INPUT_REGISTER
Ignored Entity:altddio_in
Ignored From:
Ignored To:input_cell_L
Ignored Value:LOW
Ignored Source:Compiler or HDL Assignment
Although the above invalid Fitter assignment Warning appears, but I can find the ALTDDIO_IN module in the Technology Map Viewer. So does it mean that the above warning has no effect on the implementation of its function?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page