Camera connection on XUPV2P

I would first check that the clocks are being received properly by the V2P. Add a T flip-flop on each input clock and drive it to an I/O or LED that is easy to scope. Check that the frequency is

1/2 of the input frequency and that you don't get runt pulses or other undesired behavior.

If your two input clocks are running O.K., but your data capture is not consistent, it is possible to run standard (non-GCLK) inputs to a DCM to adjust the clock phase. You might need to set an environment variable to force ISE to do this depending on the version of ISE you run. On my system I set: XIL_MAP_ALLOW_ANY_DLL_INPUT = 1 But that was for a very old version of Foundation, so you may not need this.

I'm not sure what you mean by sampling the camera data according to these clock signals, and then sampled again using the Bus2IP clock. I would think you need to use a FIFO to move from the camera clocks to the Bus2IP clock. Camera Link places a LVAL signal on each of the Channel-Links, so you can generate a FIFO write signal for each link independently using its own clock.

Hope this helps, Gabor

Gabor, Which camera are you using ? What is the source of this 16ns clock period ? (Probably from a camera with pixel clock frequency of 60Mhz)

If it is pixel clock from a camera and the voltage swing is about

600mV, then I am afraid that the fault lies in your custom PCB.

Did you perform impedance matching for the tracks from high speed edge connector to DS90288 Chip ? Have you used appropriate termination resistance to differential lines ? What is the distance between the chip (DS90288) and edge connector ? What is the status of power save mode pin on DS90288 Chip ?

In my experience, FVAL, LVAL and clock signals are extremely stable signals from the output of camera. And voltage swing of clock is very appropriate.

Try using chipscope pro to observe input signals to FPGA and perhaps by exporting to data to a text file and using matlab try to display resulting image.

Hope this helps.

/MH

based

high

Chip

chips on

but

to

The

data

these

a

clock

want to

working!

debug

Hi, thanks for the replies,

I thought my PCB might be the problem. I didn't perform any impedanc matching or termination. I'm "tapping-off" the signals between the camer and framegrabber. So i have a straight through connection - camera t framegrabber and then "tap-off" the LVDS data-signals and clock and sen these into the DS90CR288A. This way I can setup and control the camer using the camera software on PC, and just perform data processing o FPGA.

I wasn't sure I needed to terminate the lines, as this would be performe further up the line - at the framegrabber end. The pixel clock from th camera should be 66MHz (I think), so thought I was on the right lines wit a 16ns period. The chip however is the 85Mhz version. Is this a maximum I'm not sure what the clock output of the chip should be - 85Mhz o

66MHz!?

I can see data on the output of the chip, LVAL and DVAL signals ar correct, not sure about the clock. As I say, the output voltage swing i about 600mV, and looks sinusoidal in shape on the scope - Sorry for th description! The distance between the chip and the connector is abou

10mm. Do i need termination resistors across the differential lines in m case?

Tapping into 7 * 66 MHz = 462 Mbps LVDS lines needs to be done carefully to avoid signal integrity problems at the receiver. However if your LVAL and DVAL signals look correct, you may have lucked out...

Channel-Link receivers have a wide frequency range of about 20 MHz minimum to the specified maximum (66 or 85 MHz). 66 MHz should work fine.

You may be OK with the 10mm stubs. Definitely don't terminate them if there is already termination at the framegrabber. Also if you still get a proper picture at the framegrabber, you probably have reasonable signal integrity. With your scope it would be hard to look at this...

I'm going to guess that the clock is correct, too, but that your scope is bandwidth limiting the signal to form the sine wave you see. What is the input bandwidth of your scope and probe? Did you try to implement a simple T flip-flop in the FPGA to see if the clock is getting into the chip OK?

Regards, Gabor

camera

send

performed

the

with

maximum?

is

the

my

Thanks again Gabor..

The system does seem to be working ok. I get the correct image at th frame-grabber end, and all the signals do seem to be correct. The scop I'm using says 60MHz on it, I guess this the bandwidth - in which I gues it will struggle to observe the higher frequency signals??

I implemented a T-flip flop, and got a decent signal at half the inpu frequncy across an LED on the board, so it looks like everything is ok probably just my VHDL letting me down! The LVAL, DVAL signals are workin as expected aswell - used the LEDs to observe these.

Just as an aside - when I increase the precision of the camera's output bit to 16 bit, the camera sends the data in two "packets". For one LVA pulse, the are two DVAL pulses. I think this maybe camera specific, but think the data may be being sent low bits (0-7) with the first DVAL pulse followed by high bits with the second. My camera is always is i camera-link BASE mode. I've scoped all the data channels from the chip and the higher outputs are not used - apart from RxOut 27. Am I righ thinking that in base mode the data should be re-created as:

Bit(0) - RxOut 0 Bit(1) - RxOut 1 Bit(2) - RxOut 2 Bit(3) - RxOut 3 Bit(4) - RxOut 4 Bit(5) - RxOut 6 Bit(6) - RxOut 27 Bit(7) - RxOut 5

Just wondered if anyone else had any experience with 16 bit data in bas mode?

Regards

Marc.

The bit assignments are all in the Camera Link Specification:

Most Camera Link cameras use two 8-bit "ports" A & B to output

16-bits on each clock. I'm not familiar with any cameras that use DVAL as a pixel framing signal. Base Camera Link supports up to 24 bits of data per clock.

Regards, Gabor

Hi,

Gabor is right, As an addendum to his comment, I think that some cameras from "Basler" use DVAL as pixel framing signal. It is used when the user want to output some selected region from CCD of camera. If you are getting two pulses of DVAL, check your camera whether it is operating in single or dual tap mode and what is the region of interest in camera setting.

Hope this helps,

/MH

Thanks,

My camera operates in 2-taps interleaved mode. It operates as a line sca camera, a single row value for each column of the sensor array i calculated and read out. Therefore I don't think the ROI will come int it, but I'm not sure what the taps refer to or their definition, an haven't had any luck in finding out...?

The term "taps" come from the CCD world, where video comes out as a serial analog stream from the sensor. In larger sensors, the array was read out with more than one analog shift register or CCD where a CCD might read out a quadrant or half of the sensor array. Each of these output streams is called a "tap" and would be digitized independently to provide the necessary readout bandwidth.

In some older cameras, the framegrabber would need to re-assemble the multiple taps into an image, possibly getting data in a different order for each tap. One example of this is a four quadrant CCD read out at the four corners of the array. When shifting out the data, you would get the four corner pixels first and scan through in raster fashion toward the final central pixels. In this case you have all combinations of left-to-right, right-to-left, top-to-bottom, and bottom-to-top scanning. Modern cameras might use similar CCD devices, but generally re-order the data within the camera electronics so the output looks like a simple raster.

Interleaved tap order usually refers to odd / even pixels coming out of two taps of the camera. In this case each tap services every other pixel of the entire image, so the resultant image is formed by merging (interleaving) the two taps to form a single raster.

For Camera Link, the number of "taps" usually refers to the number of digitized pixels sent on each Camera Link pixel clock, regardless of the organization of the sensor. The same camera may operate in 1, 2, or 4 tap modes for example using Medium camera link and

8, 16, or 32 bits per clock.

You may find more information in the technical manual of your camera. These are usually available from the vendor's website and have more detailed information that the user manual that ships with the camera.

HTH, Gabor

is

scan

into

Thanks Gabor.

I managed to get my head round this... While LVAL is high, a full line (i my case) is delivered by the camera - 1536 values. With a higher precisio option the values are 10 bit - but everything from the camera is sent a

16bit data. The line is divided up into 2 DVAL pulses. On the first puls the pixels 1-768 are read out, the second 769-1536.

If however a lower precision is chosen, the values are 8 bit. In this cas DVAL is the same as LVAL. On each clock pulse, 16 of the RxOut channels ar used to describe 2 pixels, so thats 2 pixels read out on each clock pulse.

Thanks very much for your help, my systems *appears* to be working. Hop the above info is of use to others.

Regards

Marc.

It may be more useful if you mention the model of camera you're using :)

Regards, Gabor

Agreed!

SICK IVP Ranger C.