Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

HD SDI and Clocked Video Input issues

I'm having trouble integrating an HD SDI transceiver into my existing Stratix IV GX video design. I've ended up stripping it down to a single video path and integrating in the AN600 design to debug the issues, but I'm still unable to get valid video through the system.

My SOPC system is as follows:

CVI -> CRS -> CSC -> Deint (Bob, no buffering) -> CPR (parallel -> serial) -> Clipper (no clipping) -> Scaler (1920x1080 to 640x480) -> VFB (triple buffer) -> CPR (serial -> parallel) -> CVO

The conversion from parallel to serial and vise versa is an artifact of the pre-existing design. The clipper is currently software configurable but not clipping any of the frame.

I have the AN600 Rx-only transceiver driving the CVI. I have the Tx-only transceiver with the test pattern generator hard coded for HD SDI (tx_std = "01"). Using SignalSpy, I can see the data port on the Tx and the Rx sides and everything looks good. I'm seeing valid Vsync, Hsync and Field flags and the Rx_status is 0x01D indicating it has achieved PLL, alignment, TRS and Frame lock.

Looking at the CVI using SignalSpy, I'm seeing the overflow flag set constantly. I'm seeing valid Vsync, Hsync and Field flags. The active_line_count_f0 is 0x0C48 and active_line_count_f1 is 0x0439?? The total_line_count_f0 is 0x0465 and total_line_count_f1 is 0x0467. total_sample_count is 0x1131?? The CVI internal locked flag periodically deasserts for a full video line period.

When I configured the Clocked Video Input module, I used the SDI 1080i60 preset.

Does anyone have any input on what could be wrong here? Any advice on what to look at?

12 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    have you checked the Avalon ST ready signal into the CVI? sounds like something down stream is creating back pressure

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I would guess that it's the parallel/serial conversions that are causing the problem. 1080i input @74.xx MHz, de-interlaced to 148.xx MHz, then you are re-sequencing 3 planes in parallel to serial? How fast is your SOPC clock?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Yea, that was my suspicion, as well. My internal clock is running at 150MHz. I pulled out the CPR blocks and reconfigured the other blocks for parallel color planes. It's a step in the right direction. Now I'm seeing what appears to be 3 sets of color bars across in a scrolling zig zag pattern.

    The CVI no longer loses lock, but it still indicates overflow. The Avalon ST ready signals between each of the blocks appears to cycle between asserted and deasserted with a very regular frequency. They look like a clock signal with a period equal to the incoming video line rate. It appears to be a back pressure issue still.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I should point out that I had originally started development with a TPG inserted in the system in place of the CVI until we received an HD SDI camera. That worked fine, but I assume the TPG responded to the backpressure without overflowing like the CVI, so the effective frame rate was likely lower than 30fps. I have not confirmed this in SignalSpy, though.

    I attempted to simulate the design, but the transceiver models apparently don't simulate the dynamic reconfiguration properly. I see the dynamic reconfiguration complete, but as soon as the transceiver requests reconfiguration, the PLL loses lock and the recovered clock stops transitioning (as expected). However, after reconfiguration has completed, the transceiver fails to lock to the incoming signal and the recovered clock never starts back up. I submitted a service request but the response was

    "i regret that the reference design is just used to show the capability of the products. we don't provide the support if customer want to run the rtl simulation in modelsim.

    i hope you could understand.

    thank you and have a nice day."

    Seriously? :confused:
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Sounds like you're making some progress. 150 MHz might be cutting it a bit too close, considering the overhead of the Avalon bus. I'd try upping it, if possible.

    Also, how big is the FIFO in the CVI, it might not be big enough to cope with the backpressure from the Scaler. You might also want to experiment with putting framebuffers before and after the scaler (only one of them needs to be triple buffered) if you can afford the bandwidth. I've had success with that in the past. If you're only ever going to scale down to 640x480, you may be able to get away with just a large FIFO in the CVI and a framebuffer downstream of the scaler.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Good timing. I had just come that conclusion a few minutes before your post and kicked off a build with my core clock increased to 200MHz.

    The CVI FIFO is set to 4000 per the UDX4.1 reference design.

    The current design only outputs VGA resolution, but the next generation will move to an HD output, likely XGA or 1080i.

    Thanks for the help!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    No problem.

    If you just kicked off a build, I guess you'll have to wait until morning when it finishes to find out...:D
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    So that didn't completely fix the problem. The Avalon ST ready signals now look like a clock with a 70-30 duty cycle and the video still looks like 3 sets of color bars across with the scrolling zig zag.

    I've moved the frame buffer between the CVI and the CRS to see if I can at least get a full frame buffered.

    Interestingly, the UDX4.1 reference design uses a 148.5MHz video core clock with the following video pipeline:

    CVI -> AFD Extractor -> Switch -> Clip -> Snoop -> MA Deint -> AFD Clip -> Scaler II -> VFB -> CRS -> CSC -> ........

    There has to be something else up in my system. I'm going to work on getting a sim up and running.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Nope, not yet.

    I had to spend some time getting the simulation up and running properly. It's running now, albeit rather slowly. At ~3ms in, I'm not seeing any problems yet. I'm not seeing the CVI overflow and all of the Avalon ST handshaking is looking good. It appears to have plenty of bandwidth in that clock domain, especially now that it's running at 200MHz.

    I have another build running in Quartus to test it in the hardware again.