Forum Discussion

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

anyway to improve the reliability of triple SDI rx IP

Hi

My design has a triple SDI transceiver and several video processing IPs.

A basic test for this design is to use video standards of SDI (487i, 576i, 720p, 1080i, and 1080p) as input and to see if the SDI receiver is alignment locked, TRS locked, and frame locked in the signal of rx_status .

My problem is my design cannot always have good rx ability after each compilation.

For example, the SDI transceiver sometimes cannot be frame locked for a video standard after I only change some parameters in a video processing IP.

This situation really troubles me because I don't want to compile my design for several times until I get a good rx ability for the SDI transceiver.

I'm trying two ways to solve my problem, but they all fail...

1). Use design partition and logiclock:

I separate this design into the SDI transceiver and a qsys which includes video processing IPs in design partition.

Once I have a good compilation result which passes my basic test for rx ability.

I keep the post-fit netlist of SDI transceiver in design partition window and fix its location and size in logiclock window in order to preserve its performance.

Design partition and logiclock are quite new things to me. I'm not sure if I used them correctly.

2). Add timing constraint and try to solve negative slacks:

By referring to the SDI user guide appendix A and the SDC file in Altera reference design, I add some timing constraints such as set_clock_groups and set_false_path.

I have a feeling that adding these constraints does not help a lot on solving negative slacks.

Negative slacks are still negative even though some of them become smaller.

I don't have much experience in adding timing constraints to solve negative slacks, so I have my SDC file as attachment.

Could anyone give me some suggestions about my question?

Thanks a lot.

5 Replies

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

    Hi,

    I'm not familar with SDI. Maybe you can describe it and your receiver a bit more?

    Meanwhile, some general suggestions:

    1) Setting constrains and fixing the negative slacks is *the* way. Working without *correct* constraints is working without safety net.

    2) Using LogicLock is not an alternative to setting constrains (nothing is) but may be a way to fix negative slacks.

    3) Clock groups and false paths are used to simply remove paths from analysis. This should only be used when the paths are indeed asynchronous (and hence not possible to analyse) and you are using asynchronous design techniques. Otherwise, you're just sweeping issues under the carpet.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Hi rbugalho

    Thank you for the reply.

    To my understanding, the SDI receiver recoveries clock data, decodes bit stream from NRZI, and descrambles bit stream.

    If the SDI receiver works fine, SDI receiver outputs uncompressed 20-bit video data in YUV422.

    I'm studying on how to remove all the negative slacks today but have more questions about timing constraints.

    For example:

    1). In my design, there is an input pin connected to a button and used as a reset signal. Should I use "set_input_delay" to constrain this input? (My answer is "no" because a person can hit this reset button at anytime)

    2). My design has 20 output pins for 20-bit YUV422 parallel data and a output clock pin. The clock on the output clock pin is synchronous to the data and its frequency is either 74.25MHz or 148.5MHz. Should I constrain this clock and use "set_output_delay" to constrain the 20-bit data?

    Thanks.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    How do you recover the clock?

    1) Indeed, that input is not synchronous to any clock. Thus, you should not use set_input_constrains. What you should do is create a synchronized reset like this:

    process(external_async_reset, clock) begin

    if external_async_reset = '1'

    internal_sync_reset <= '1'

    elsif rising_edge(clk)

    internal_sync_reset = '0';

    end process;

    You should then use internal_sync_reset as reset within your design, instead of external_async_reset.

    You should also add a false path exception on all paths from external_async_reset.

    set_false_path -from [get_ports external_async_reset]

    2) Yes. You can create two derived clocks on that output clock pin, one for the 74.25 and another for the 148.5 MHz one. Then you can add constraints between the data pins and both.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Hi rbugalho

    The SDI receiver IP is from Altera so I don't know how the clock recovering is implemented in detail.

    I just know its functions and IO signals.

    I am now trying to solve all the negative slack.

    Luckily, I solve most timing violations by adding asynchronous clock groups.

    (My design has other clocks for audio data and other modules which are not related to the video clock.)

    Hope I can solve the rest timing violations.

    Thank you for your help.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Errr....based on my experience with the core and the inner working, I feel that it is not the core that is affecting you. It is possible that your external stuff like jitter, power supply and noise that is affecting your stability.

    One way to verify is to just run at HD-SDI, with 74.25MHz clock, and try various format. If you are still having problem, then it is definitely your external stuff.