Construct Image 3 taps 16-bit Camera Link Camera using NI 1483

[Shazlan]

Hi Jeff,

Actually, the camera has a base configuration and thus, there's only one Camera Link connector. Using their own program, the clock cycle that we normally choose (for lowest noise possible) is 100 MHz. 

Anyway, I've just started modifying the LabVIEW FPGA example to suite with this camera. Do you have any ideas on how to best capture 1.5 pixels for every cycle? If I set the FPGA acquisition loop to run at 100MHz (1st loop to send the first pixel and store in a shift register half of the second pixel and the second loop to send the second and third pixel), this doesn't work since I cannot send two pixels at the same (during the second, even numbered loop). I then tried setting the loop timer to 200MHz (first loop sends the first pixel, second loop doesn't do anything, third and fourth loop send second and third pixels, respectively, and all these are enclosed in a case structure) but faced another problem since I cannot have multiple instances of DMA node. Can we set the clock cycle to be 66.67 MHz?

[natmojo]

Shazlan,

Regarding the 2 clock delay in the pixel path... This is placed to keep the FLAGS (LVAL, FVAL) synchronized with the data.  The Aquisition State Machine block delays the FLAGS by two clocks.  It is important to keep the flags and pixels synchronized for down-stream processing stages.

Regards, Jeff

[Shazlan]

Hi Jeff,

Thank you for reply, but can you please clarify what do you mean by 2 clock delay in the pixel path?

Shazlan

[natmojo]

Shazlan,

If you open the block diagram of "Acquisition State Machine.vi" or the example: 1-Tap 10-Bit Camera with Frame Trigger.lvproj

You will see that there is a feedback node right after the unbundling of the Enables.  The dataflow, graphical representation is of hardware running on the FPGA.  Another way to think of the feedback node is a Flip-Flop, if that helps. The Flip-Flops are clocked with the 100 MHz source clock for the loop. 

The Capture Cycle output is passed through a second feedback node before being wired to the indicator (output port of the VI)

From beginning to end, there is too much logic for the signals to pass through the associated FPGA fabric in a single 100 MHz clock period.  In order to meet timing in the FPGA, we must break up the logic into smaller chunks and "pipe-line" the signals.

The Capture Cylcle output indicates which clock cycles the data from the camera should be captured as part of the current acquisition.  In other words, when the Capture Cycle output is TRUE during clock cycles where camera data is currently valid, the corresponding pixel data should be captured.

In the example(1-Tap 10-Bit Camera with Frame Trigger.lvproj), the Capture Cycle output is used as the input to the case structure that forwards pixel data to the Host DMA FIFO.

If the 2-clock feedback node were not added in Step #5, to the pixel path, then the pixel data would be out of sync with the enables.  In this case, you would miss the first two pixels of every line and capture two clock periods of invalid data between lines.

Regards, Jeff

[natmojo]

Shazlan,

Does the camera output data with a 100 MHz pixel clock?

-Jeff

[Shazlan]

Hi Jeff,

Yup. I did some tests yesterday. See the two images (shot1 and shot1_solis). I've set the capture rate of the image to be every two seconds. As a result, the acquired frame width and heigth matches what I expected. Here's how I did my calculation:

The image size is 2560 x 2160. The pixels are being captured 1.5 pixels per clock and being mapped horizontally, starting to top left. Since the calculation in the example program calculates the height and width of the frame by assuming 1 pixel per clock, so 1712 x 1.5 = 2568 (thought I don't know why is there an extra pixels). 

However, I cannot say the same thing about the image generated from the pixels. One thing I realised, though, is that I kept on getting DMA Write timeout... I believed I've set the DMA buffer size to be large enough. The program (modified from the example) is attached. Any ideas why? 

Really appreciate the help!

[natmojo]

Shazlan,

I noticed a couple of things...

First, the source clock for the acquistion loop must match the "Image Data Clock" that is configured for the 1483.  You can view/configure the 1483 clock source by right-clicking on the IO Module in Project Explorer and selecting properties, then Clock Selections.  You should not need to set this above 100 MHz.  The Camera Link specification states that the allowable pixel clock frequency range is 20 MHz to 85 MHz.  I suspect that the "Pixel Readout Frequency" of the camera is for the path between the sensor and on-board memory and that the Camera Link Pixel clock over the cable is much slower.  My suggestion is to change the acquistion source clock back to 100 MHz.  This mismatch in frequency could explain the DMA timeout.  

Another thing is that your use of the "Join Numbers" element is reversing the byte order.  Make sure you maintain the lo byte and high byte wiring from the camera link ports.

Other than that, nothing jumped out at me.

Regards, Jeff

[Shazlan]

Hi Jeff,

Sorry, by the time I've posted the message, I've done a few tests on the FlexRIO. My original code has the clock cycle to be set at 100 MHz - the 200 MHz never actually worked, as I've always got some compilation errors and never bothered to troubleshoot any further. Is it possible to custom-set the FPGA clock to any value that we want? In this case, instead of using 100 MHz, we might as well drop the frequency to 85 MHz. Hopefully, this will slows down the DMA write cycle, which in-turn will reduce the burden on the host program to empty the DMA buffer as fast as possible.

With regards to the 'join numbers', on the first cycle, I have Tap A connected to 'lo' and Tap B connected to 'high'. Then, on the next cycle, I have Tap C (of the previous cycle, something which I have no idea on how to do the program yet) connected to 'lo' and Tap A (of the current cycle) connected to 'high'... and this goes on... is this correct?

Shazlan

[natmojo]

Shazlan,

The FPGA 1483 CLIP and Acquisition clock should be set to 100 MHz.  It must be greater than 85 MHz to insure that no pixels are dropped.

Your description of the "join" logic sounds correct.

It occurred to me that the pixel unpacking will not be able to keep up with the acquistion as it is implemented.  The current implementation only writes 16 pits per 100Mhz clock to the DMA FIFO, but the camera is sending 24 bits per clock.

Here is an implementation that I think will work for you.  I don't have a camera to test with, but it should be close.  Basically, it widens the DMA FIFO to 64 bits and writes to it every other 100 MHz clock period.  The 64-bit DMA FIFO will be more efficient as an added benefit.  The downside is that 16 of the 64 bits are unused.

You will have to modify the 16-bit FIFO, or create a new FIFO that is 64-bits wide and add it to the project.

You will have to modify the host VI to extract the 3, 16-bit pixels in a way that is similar to other mult-tap examples.  Take a look at the 10-Tap 8-bit Camera with DRAM (Host) VI for ideas on how to do this.

Regards,

Jeff

[Shazlan]

Hi Jeff,

Many thanks for the code. Packing the pixels together is a challenge that I know I will have to face sooner or later, but your VI has certainly got me somewhere. 

I'm currently struggling to compile the code without timing error and at the same time, to solve the DMA Write Timeout error I kept on getting. What I've done is to try to send the raw pixels to a memory (DRAM) and to retrieve them from the memory into the DMA FIFO. The goal is for the DRAM to act as a temporary storage of the pixel values while waiting while waiting each of their turn to be pulled out by the host DMA FIFO and once the FIFO is full, data from the DRAM will not be forced to the DMA FIFO (and causing the DMA Write Timeout error).