Random results on FPGA

--- Quote Start ---

Hello,

I'm using altera devices for about 10 years with quartus or quartus + synplify pro.

I'm currently struggling for about a month !!! on this issue:

Using the same netlist from synplify pro, the same timing constraints, and doing the place and route with quartus,

I can get total different results on FPGA (stratix III): fully working, or failing on first HW accesses.

The IP in the FPGA uses a lot of clock gating and I think that Quartus is not doing a good timing analysis (timequest reports no timing violations and the design is fully constrained),

leading to such random results.

Did you ever face such problem at your place ?

Metastability report in timequest reports no problem.

Resets are ok.

Cooling the FPGA does not change anything.

I never faced such situation before.

I need help !

Alex

--- Quote End ---

Is it random per build or per download or per reset?

If it is per build then what do you change to rebuild?

If it is per download(of same one build) then it points to power up reset issues.

If it is per reset(one download) then it is due to your reset. Try changing its duration.

do you have multicycle deconstraint? if so double check them.

Also check your clock signal and voltage levels.

It is random per place and route.

When it fails, it always fails at the same point after several resets or re-sof.

I change nothing between build.

no multi cycles. Few false path but for debug ports.

Voltage is ok (1.1V). Clocks are ok.

--- Quote Start ---

It is random per place and route.

When it fails, it always fails at the same point after several resets or re-sof.

I change nothing between build.

no multi cycles. Few false path but for debug ports.

Voltage is ok (1.1V). Clocks are ok.

--- Quote End ---

If you change nothing between builds then I assume the fitting results should be more or less identical. Therefore (my guess) it is likely your problem is to do with reset functionality per se which appears at power up or afterwards. I believe the place and route variation is just coincidence of same issue.

I mean some registers are not under reset. You need to check that your control signals are all under reset. You can also uncheck powerup don't care in the fitter settings so that all registers power up low(except preset ones). Finally you may add signaltap to capture the events at failure. You may find a work around if you play with the duration and release of reset until you find a stable window.

also check for any floating inputs which are not driven at your development stage

This is not a reset issue, it is properly driven, synchronized and with a long duration.

power up don't care is already unchecked.

There is no floating inputs.

I think the report is too vague to seriously guess about the problem cause.

I'm surprised about the "lot of clock gating" point. By nature of the clock networks, FPGAs are not designed to implement clock gating effectively, with the exception of those cases where clock control blocks or PLL blocks hold in reset can be utilized. Timing analysis should still work, but we don't know much about the design, see my first point.

Well, indeed, this is bad to use clock gating in FGPA.

The problem is that they use the clock gating feature to reduce the clock speed (so the duty cycle is far from 50%).

Before I was removing the gating succh that all mappings were stable and consistent, but without the clock divison feature.

Thanks for your feedback anyway.

Mmmm I just found something interesting,

the same sof does actually give different results depending on another parameter (an external uart connection),

I will investigate that.

One of the uart (another one) is not connected and so has floating pins. I Will fix that.

How about if you heat the chip up in an oven or use freezer spray on it? Does that make problems appear and/or go away?

Is the clock gating/clock divider done by generating logic clocks (like using the MSB of a counter)?

spray does not chane anything.

I just found that programming another FPGA that is on the board (dual stratix 3),

that makes it to work or not.

I'm looking into it.