Debugging interface issue on FPGA

--- Quote Start ---

I have a data processing module that takes only clock and reset as input and generate an expected sequence of data.

--- Quote End ---

This is a pretty vague description. Is this data generated and used by on-chip logic, or does it go off chip to some other devices?

--- Quote Start ---

When this design is tested in stand-alone mode, it works fine. But when integrated in a larger system the output is messed up.

--- Quote End ---

'Works fine', 'messed up'; again pretty vague.

What have you tried, eg., have you created a simulation of the design and checked that it passes your tests in stand-alone mode and integrated into the system, have you looked at the data with SignalTapII, what is the difference when data is Ok versus 'messed up'? Can you use data that has an obvious pattern, eg. a counter or a PRBS sequence?

--- Quote Start ---

I looked at synthesis warnings to make sure none of the data processing module signals are trimmed. STA report has no timing violations. The clock and reset going to data processing module are clean.

--- Quote End ---

Is there only one clock, or are you using the PLLs to generate more clocks?

Cheers,

Dave

The data generated is sent off the chip to other device.

The data is passed through a DAC and observed on oscilloscope. In stand-alone mode, the output on oscilloscope is repetitive with a fixed pattern. When integrated in bigger system, the output is still repetitive but the pattern is wrong.

I made sure that my module takes only clock and reset as input when integrated in bigger system to isolated data dependency problem.

This integration of bigger system is done by a different team at different location and I do not have access to the board.

Thanks

I was curious to know if any of the users faced a problem with Quartus where their design works fine in stand-alone mode and when integrated in a bigger system it fails. Assuming that the design has no problems and all the reports are clean.

Thanks

--- Quote Start ---

The data generated is sent off the chip to other device.

The data is passed through a DAC and observed on oscilloscope. In stand-alone mode, the output on oscilloscope is repetitive with a fixed pattern. When integrated in bigger system, the output is still repetitive but the pattern is wrong.

--- Quote End ---

And what does your Modelsim simulation of both systems show you? Is the design constrained for timing correctly in both cases?

--- Quote Start ---

I made sure that my module takes only clock and reset as input when integrated in bigger system to isolated data dependency problem.

This integration of bigger system is done by a different team at different location and I do not have access to the board.

--- Quote End ---

You need to look at the simulation output from both the small system and the large system. You should do this for both pre-synthesis and post-synthesis.

Cheers,

Dave

--- Quote Start ---

I was curious to know if any of the users faced a problem with Quartus where their design works fine in stand-alone mode and when integrated in a bigger system it fails. Assuming that the design has no problems and all the reports are clean.

--- Quote End ---

I've designed lots of systems, and if they work in simulation, are correctly constrained for timing, synthesize and meet timing, then I can not recall any failures in hardware. If the tools are used correctly and the hardware is designed correctly, then designs downloaded to the hardware work.

Cheers,

Dave

--- Quote Start ---

I made sure that my module takes only clock and reset as input when integrated in bigger system to isolated data dependency problem.

--- Quote End ---

So where does the data come from? Something with only clock and reset must have a data source internally, so what is it?

Cheers,

Dave

I have DDS for generating constant data. This data passes through different blocks, where it is modified in certain format. Once I resolve this issue, I will be replacing DDS with streaming data.

I have constrained the design and the small system works fine on hardware. When the small system is tried at different location, it worked fine on hardware too. Synthesizing large system with constraints does not report any violations. Since the large system is too big and has lot of latency, simulation is not an option.

Thanks for all the support.

--- Quote Start ---

I have DDS for generating constant data. This data passes through different blocks, where it is modified in certain format. Once I resolve this issue, I will be replacing DDS with streaming data.

--- Quote End ---

And all these blocks have been tested with this type of signal? You're sure that your sinusoid is not being clipped or aliased by some subsequent processing step? (Just trying to offer a few ideas).

--- Quote Start ---

I have constrained the design and the small system works fine on hardware. When the small system is tried at different location, it worked fine on hardware too. Synthesizing large system with constraints does not report any violations.

--- Quote End ---

Ok.

--- Quote Start ---

Since the large system is too big and has lot of latency, simulation is not an option.

--- Quote End ---

I'm not sure I follow you here. What does having a lot of latency have to do with simulating not being an option? Do you mean that the design does not enable this particular component until too much simulation time has passed? Perhaps you can hard-wire an example version of the design to simply turn on the problem component at power-up, so that simulation can become an option.

Failing that, make use of SignalTapII. Probe the output of your DDS and confirm that is outputting the correct data, then work your way along the datapath until you get to the output pins. Somewhere along that path, you will discover where things are going wrong. Actually, each time you change the SignalTapII location, you will need to resynthesize the design, so it might be better to use a divide-and-conquer approach (after checking the DDS output is ok); start in the middle of the signal processing chain and see if that is fine, and then move to the middle of the half that still has the problem.

Cheers,

Dave