Performance varies with different compilation

--- Quote Start ---

Hi all,

I'm doing an DVB-ASI PCIE card. On this card, my FPGA receives DVB-ASI signal by using Altera ASI IP and converts it to parallel transport stream interface. The transport stream data are then sent to a PCIE bridge chip for PC decoding.

I found that the FPGA performance is different after each compilation. (No change to the RTL codes, IP, or timing constraints)

In some compilation results, the transport stream data can be successfully decoded and the video can be displayed. In other compilation results, the transport stream data cannot be decoded.

For those cases that the transport stream data cannot be decoded, I find that the transport stream data sent to PCIE bridge is incorrect.

I don't know what to do in order to make each compilation has good performance.

Should I add more constraints on my design or change my RTL code?

(My constraints now are some frequency constraints on clock, clock group constraints, and required constraints for Altera ASI IP)

I really don't have any idea now. Any suggestions are appreciated.

--- Quote End ---

can you simulate it functionally first. Possible causes:

io timing

fpga timing failure or timing passes but wrong constraints/deconstraints or wrong false paths

inadequate synchronisation across clock domains

buffers getting underflow/overflow

reset issues(check your simulation under different reset lengths.

any inputs being floating

...etc.

does failure/pass occur per build or per download powerup or per reset?

is it freeze sensitive? => timing

is it touch sensitive? => floating pins

Hi Kaz, thank you for the reply.

I forget to mention one thing last week.

There are two DVB-ASI inputs on this card.

In different compilation results, the transport stream data in the 1st input cannot be decoded more often than the 2nd input. But the RTL code and timing constraints for both inputs are the same.

Regarding to the possible causes you mentioned:

1). io timing: I use oscilloscope to see the timing relation between clock and data in both inputs. I think they are acceptable by the PCIE bridge chip.

2). fpga timing failure or timing passes but wrong constraints/deconstraints or wrong false paths: I have only one negative slack in my design. I'll check this part today.

3). buffers getting underflow/overflow: for the FIFO I used in my design, the overflow flag is never set to 1.

4). reset issue and any inputs being floating: my design now doesn't have a reset pin. So I only declare a reset input signal in my top module and do not assign pin location to this reset input signal.

5). does failure/pass occur per build or per download powerup or per reset? per build

--- Quote Start ---

Hi Kaz, thank you for the reply.

I forget to mention one thing last week.

There are two DVB-ASI inputs on this card.

In different compilation results, the transport stream data in the 1st input cannot be decoded more often than the 2nd input. But the RTL code and timing constraints for both inputs are the same.

Regarding to the possible causes you mentioned:

1). io timing: I use oscilloscope to see the timing relation between clock and data in both inputs. I think they are acceptable by the PCIE bridge chip.

2). fpga timing failure or timing passes but wrong constraints/deconstraints or wrong false paths: I have only one negative slack in my design. I'll check this part today.

3). buffers getting underflow/overflow: for the FIFO I used in my design, the overflow flag is never set to 1.

4). reset issue and any inputs being floating: my design now doesn't have a reset pin. So I only declare a reset input signal in my top module and do not assign pin location to this reset input signal.

5). does failure/pass occur per build or per download powerup or per reset? per build

--- Quote End ---

For a design like that you need reset. It seems you are reliant on powerup values after configuration. Though you can set that to zero project wide (poweup don't care option unchecked) but Altera recommends user reset since they might power up wrong due to the uncertainty of time an external clock arrives.

You can apply reset to your control signals at least. Data path does not need reset unless you read its value for control purpose. buffers need reset to get ready. It also provides a test if design works after a reset or fails after it.