200+ MHz through a SCSI cable

the

connector

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) 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

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?

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.

Hi John,

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

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