200+ MHz through a SCSI cable

Hi,

I am glad to tell you, that my LCD via LVDS works now :) However it 
works only up to a lvds clock rate of about 200 MHz.

I am not sure yet, if the 200 MHz limit originates from the fpga or the 
cable. Has anybody put more than 200 MHz through a 0,4m SCSI cable?

What is approximately the frequency limit of the (50 pin) scsi connector 
on my board? (assuming my cable is perfect)

regards,
Benjamin

Benjamin Menk=FCc wrote:
> Hi,
>
> I am glad to tell you, that my LCD via LVDS works now :) However it
> works only up to a lvds clock rate of about 200 MHz.
>
> I am not sure yet, if the 200 MHz limit originates from the fpga or
the
> cable. Has anybody put more than 200 MHz through a 0,4m SCSI cable?
>
> What is approximately the frequency limit of the (50 pin) scsi
connector
> on my board? (assuming my cable is perfect)
>
> regards,
> Benjamin

At 200 MHz I doubt your connector is affecting the signal
significantly.
We use National Channel-Link chipsets over multiple connectors at 595
Mb/s and cable lengths up to 10 meters.  Also unless there is an
impedance
mismatch or significant line to line skew, your short cable should be
no
problem.  Impedance mismatch and skew are usually larger on the printed
circuit board rather than the cabling unless you take care during
layout
to control them.

I would suspect a clock alignment issue at this low a frequency.

Hi,

thanks for the answer Gabor. It seems that I have to do something inside 
the fpga to get it faster.

I experimented a little bit further and found out, that my limit is at 
240 MHz.

I am using a XC2VP4 with speedgrade 5.

The synthesize report says 240 MHz is the max clock for some nets, but 
these (listed) nets are not important. The important lvds_in_x nets are 
not listed there.
Is it usefull to put a bufg on every line that goes into the obufds? At 
the moment these are just normal nets. (see the code attached).

At the moment I use a DCM to generate the 240 MHz.
Then I use a process, to divide the clock by 7 and form the asymmetric 
clock. (see the code attached).

When I simulate my code in modelsim as Post-Map, everything looks okay. 
But when I do Post-Place & Route the clock lvds channel and the data 
channels are off by 1 lvds-clk cycle (I mean 1/240MHz), furthermore the 
lvds-data-channel with the DTMG (Data Pixel Enable) doesn't go high (on 
active) anymore, instead it becomes X for the high time. (However in 
Hardware it works.)

My goal is about 350-400 MHz.

Maybe I should set some contraints, what would be a good starting point 
for that?

I am happy about any hints that could help me.

Thanks in advance.

regards,
Benjamin



lvds3(6)<=DTMG;
lvds3(5)<=VSYNC;
lvds3(4)<=HSYNC;

-- generates serial data for one lvds-pair
lvds_1:process (lvds_tick)
begin
    if rising_edge(lvds_tick) then
	if load_lvds='1' then
		reg1 <= lvds1;
	else	
       		reg1 <= reg1((5) downto 0) & '0';
	end if;
    end if;
    lvds_1_in <= reg1(6);
end process;

lvds_clk_obufds : OBUFDS
port map (
       O => lvds_clk_p,
       OB => lvds_clk_n,
       I => lvds_clk      -- Buffer input
);

lvds_3_obufds : OBUFDS
port map (
       O => lvds_3_out_p,
       OB => lvds_3_out_n,
       I => lvds_3_in      -- Buffer input
);

-- lvds_tick is a clock at 7x pixel-clock	(240 MHz)
-- lvds_clk is the clock for the lvds bus, same as pixel clock, but not 
symmetric
-- like this for one pixel period: --___--
process (lvds_tick,screen_reset)
begin
	if screen_reset='1' then
		lvds_div<=0;
		row_count <= 0;
		col_count <= 0;
		DTMG <= '1';
		VSYNC <= '0';
		HSYNC <= '0';
	elsif rising_edge(lvds_tick) then
		case lvds_div is
			when 0 to 1 =>
				lvds_clk <='1';
			when 2 to 4=>
				lvds_clk<='0';
			when 5 =>
				lvds_clk<='1';
			
				------------
				-- vsync and hsync stuff
				
				case col_count is
					when num_col -1  =>		
						DTMG <= '0';
						if row_count = num_row -1 then
							VSYNC<='1';
						elsif row_count = num_row +1 then
							VSYNC <='0';
						end if;
						HSYNC <= '1';
					when num_col + 20 =>
						HSYNC <= '0';
					when others =>
				end case;
				if col_count = num_col + 60 then
					col_count <= 0;
					if row_count < num_row -1 then
						DTMG<='1';
					end if;
					if row_count = num_row + 3 then
						row_count <= 0;				
						DTMG<='1';
					else
						row_count <= row_count +1; 			
					end if;
				else
					col_count <= col_count +1;
				end if;			
				-------------
			
			when 6 =>									
				lvds_div <= 0;


			when others =>
		end case;
		if lvds_div < 6 then
			lvds_div <= lvds_div +1;
		end if;

	end if;	
end process;

Hi,

after I set the optimization effort to "high", I can get the whole 
270MHz now (thats all the DCM can generate out of 100 MHz).

Any comments how to make my design better are still welcome though :)

regards,
Benjamin

Hi,

I am running my design now with two dcms cascaded. The max. clk2x output 
of my device is 360 MHz, which I am using now. That gives me for my LCD 
panel a frame rate of about 54 Hz, still not too much. Maybe I have to 
switch to a faster speed grade or experiment with external clocks.

regards,
Benjamin

Do you have to supply the actual 360 MHz as a clock with your LVDS data?  If
you supply a lower frequency clock or no clock at all, consider the DDR
capability available in the families with DCMs to improve the output rate by
a factor of 2.  720 Mbits/sec?

"Benjamin Menk&#4294967295;c" <benjamin@menkuec.de> wrote in message
news:d589f7$d17$03$1@news.t-online.com...
> Hi,
>
> I am running my design now with two dcms cascaded. The max. clk2x output
> of my device is 360 MHz, which I am using now. That gives me for my LCD
> panel a frame rate of about 54 Hz, still not too much. Maybe I have to
> switch to a faster speed grade or experiment with external clocks.
>
> regards,
> Benjamin

Hi John,

the clock is actually 360 MHz divided by 7. It's an asyncronous clock 
like this "--___--". However the data goes at 360 MHz SDR. I have to use 
SDR, because the LCD doesn't support DDR.

regards,
Benjamin

The LCD has to support a data stream with a divide-by-7 reference clock.
Good info.

Using the DDR registers you can have an effective divide-by-3.5 applied to
your 360 MHz clock and DDR generated from the same 360 MHz clock.  This
looks from the outside as if it's a 720 MHz clock providing the divide-by-7
and the data running at 720 Mbits/s/pin just as if it were clocked with a
720 MHz clock.

Your LCD doesn't have to understand DDR to receive 720 Mbit/s data streams
and a 102.86 MHz clock.


"Benjamin Menk&#4294967295;c" <benjamin@menkuec.de> wrote in message
news:d5dar6$nms$00$2@news.t-online.com...
> Hi John,
>
> the clock is actually 360 MHz divided by 7. It's an asyncronous clock
> like this "--___--". However the data goes at 360 MHz SDR. I have to use
> SDR, because the LCD doesn't support DDR.
>
> regards,
> Benjamin

Hi John,

> Using the DDR registers you can have an effective divide-by-3.5 applied to
> your 360 MHz clock and DDR generated from the same 360 MHz clock.  This
> looks from the outside as if it's a 720 MHz clock providing the divide-by-7
> and the data running at 720 Mbits/s/pin just as if it were clocked with a
> 720 MHz clock.
> 
> Your LCD doesn't have to understand DDR to receive 720 Mbit/s data streams
> and a 102.86 MHz clock.

the max. pixelclock of the LCD is 80 MHz, that would be a LVDS clock of 
560 MHz. Maybe when everything works (DVI-Link is the next challange 
now), I will try to tune up the LCD to 80 MHz using your DDR methodology.

Thanks for the information.

regards,
Benjamin

Benjamin Menk�c wrote:

> Hi,
>
> after I set the optimization effort to "high", I can get the whole 
> 270MHz now (thats all the DCM can generate out of 100 MHz).
>
> Any comments how to make my design better are still welcome though :)
>
> regards,
> Benjamin

Yup,

use DDR clocking of your IOBs and double the internal path width. Just a 
sugestion without studying your code.
This should give more than 600MHz.

Regards,
Thomas